Le processus de décision du Context Engine
Le processus de décision du Context Engine
Introduction
Les deux premiers documents ont défini :
- pourquoi le Context Engine existe ;
- les principes de pertinence qui guident ses décisions.
Il reste maintenant à répondre à une question essentielle :
Comment le Context Engine prend-il ses décisions ?
Ce document ne décrit toujours pas une implémentation technique.
Il décrit uniquement le raisonnement métier du moteur.
⸻
Un moteur de décision
Le Context Engine n’est pas un moteur de scoring.
Son rôle est de prendre des décisions.
Il fonctionne comme une succession d’étapes indépendantes.
Chaque étape répond à une question précise.
Le résultat d’une étape devient l’entrée de la suivante.
⸻
Le pipeline de décision
Le moteur suit toujours le même processus.
Contexte │ ▼ Chargement des informations │ ▼ Filtrage │ ▼ Validation │ ▼ Classification │ ▼ Priorisation │ ▼ Classement │ ▼ Production des Cards │ ▼ Ajout des Actions
Ce pipeline constitue le cœur du Context Engine.
Les algorithmes utilisés pourront évoluer.
Le pipeline, lui, a vocation à rester stable.
⸻
Étape 1 — Chargement
Le moteur reçoit un contexte.
Exemples :
- contexte personnel ;
- contexte commune ;
- contexte acteur ;
- contexte recherche.
Il demande ensuite aux différents Providers de produire les informations disponibles.
À cette étape, aucune décision n’est encore prise.
Toutes les informations sont simplement collectées.
⸻
Étape 2 — Filtrage
Le moteur élimine immédiatement les informations incompatibles.
Par exemple :
- publication expirée ;
- événement terminé ;
- contenu non visible ;
- publication privée ;
- acteur désactivé.
Ces informations ne participeront jamais au reste du traitement.
⸻
Étape 3 — Validation
Le moteur vérifie que les informations restantes sont exploitables.
Par exemple :
- les données sont complètes ;
- les dates sont valides ;
- les permissions permettent leur affichage.
Une information invalide est retirée avant toute analyse.
⸻
Étape 4 — Classification
Les informations sont ensuite classées par nature.
Exemples :
- alerte ;
- publication ;
- événement ;
- information municipale ;
- commerce ;
- association.
Cette classification permet ensuite d’appliquer des règles spécifiques à chaque catégorie.
⸻
Étape 5 — Priorisation
Le moteur détermine la priorité métier.
Il ne s’agit pas encore d’un classement final.
Certaines informations possèdent une priorité supérieure par nature.
Exemples :
- alerte de sécurité ;
- fermeture exceptionnelle d’une école ;
- information municipale urgente.
Ces informations bénéficient de règles spécifiques.
La priorité n’est pas une note.
C’est une catégorie de traitement.
⸻
Étape 6 — Classement
Le moteur classe ensuite les informations appartenant à une même catégorie de priorité.
Le classement dépend notamment :
- du contexte ;
- des relations utilisateur ;
- de la fraîcheur de l’information ;
- des règles métier applicables.
Cette étape permet d’obtenir une liste ordonnée.
⸻
Étape 7 — Production des Cards
Une fois les informations classées, le moteur produit des Cards.
Une Card n’est pas un composant graphique.
Elle représente une information métier prête à être affichée.
Les interfaces restent libres de choisir leur présentation.
⸻
Étape 8 — Ajout des Actions
Chaque Card reçoit ensuite les actions disponibles.
Exemples :
- ouvrir ;
- appeler ;
- participer ;
- ajouter à l’agenda ;
- suivre.
Les Actions ne sont pas exécutées par le moteur.
Le moteur décrit simplement ce qui est possible.
⸻
Pourquoi ce pipeline est-il important ?
Il garantit que toutes les surfaces DMV utilisent exactement le même raisonnement.
Exemples :
- MurVille ;
- Mon espace ;
- Recherche ;
- Assistant ;
- Notifications.
Toutes utilisent le même pipeline.
Seule leur présentation change.
⸻
Déterminisme
Le Context Engine est déterministe.
Deux exécutions identiques produisent toujours le même résultat.
Pour garantir ce comportement, chaque étape possède ses propres règles.
En cas d’égalité parfaite entre deux informations, le moteur applique toujours le même ordre de départage.
Par exemple :
- priorité métier ;
- pertinence contextuelle ;
- date de publication ou de début ;
- identifiant stable.
Ainsi, aucune exécution ne dépend du hasard.
⸻
Les informations critiques
Les informations critiques ne contournent pas le pipeline.
Elles suivent les mêmes étapes.
En revanche, lors de la phase de priorisation, elles sont automatiquement placées dans la catégorie de priorité la plus élevée.
Le pipeline reste donc unique.
⸻
La criticité est un état
Une information n’est pas critique par nature.
La criticité est un état temporaire.
Exemple :
Une alerte météo.
Pendant sa période d’activité :
- état : actif ;
- priorité : critique.
Une fois l’alerte terminée :
- état : terminé ;
- la priorité critique disparaît ;
- l’information peut être archivée ou supprimée selon ses règles de durée de vie.
La criticité évolue donc avec le temps.
⸻
Durée de vie des informations
Chaque information possède son propre cycle de vie.
Elle peut notamment définir :
- une date de début ;
- une date de fin ;
- un état ;
- une durée de validité.
Le moteur ne traite jamais des informations devenues invalides.
La première étape consiste précisément à les éliminer.
⸻
La pertinence n’est pas calculée en une seule fois
Le moteur ne cherche pas immédiatement à attribuer une note.
Il raisonne progressivement.
Chaque étape réduit le nombre d’informations ou améliore leur classement.
Ce fonctionnement rend le moteur plus lisible, plus explicable et plus évolutif.
⸻
Pourquoi ne pas utiliser un simple score ?
Un score unique mélange plusieurs concepts différents :
- validité ;
- priorité ;
- pertinence ;
- fraîcheur ;
- contexte.
Le pipeline les traite séparément.
Chaque décision devient alors compréhensible.
Une évolution future pourra modifier une étape sans remettre en cause les autres.
⸻
Architecture conceptuelle
CONTEXTE │ ▼ Chargement des Providers │ ▼ Filtrage │ ▼ Validation │ ▼ Classification │ ▼ Priorisation │ ▼ Classement │ ▼ Production des Cards │ ▼ Ajout des Actions │ ▼ Interfaces DMV
Résumé
Le Context Engine ne prend jamais une décision en une seule étape.
Il applique toujours le même pipeline.
Chaque étape possède une responsabilité unique.
Cette séparation permet :
- un moteur déterministe ;
- un moteur explicable ;
- une architecture évolutive ;
- une maintenance simplifiée.
Les algorithmes utilisés dans chaque étape pourront évoluer au fil du temps.
Le pipeline, lui, constitue la colonne vertébrale du Context Engine et représente l’un des éléments les plus stables de toute l’architecture DMV.